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INTRODUCTION 

PLATO  [Smith  &  Sherwood  76]  is  an  excellent  medium  to  teach 
and  practice,  e.g.,  introductory  computer  science  material.   Within  the 
ACSES  project  [Nievergelt  et  al.  76]  lessons  were  developed  which  now  present 
half  of  the  usual  introductory  programming  instruction  at  the  University 
of  Illinois. 

The  system  was  less  successful  in  more  advanced  computer  science 
applications,  mostly  because  space  and  execution  time  constraints  limit 
the  complexity  of  the  instructional  approaches.   It  was  possible,  pri- 
marily for  elementary  numerical  applications  in  calculus,  to  implement 
a  subset  of  BASIC  as  a  PLATO  lesson  [White  &  Schreiner  78],  and  using 
the  same  techniques  a  FORTRAN  compiler- interpreter  was  also  developed 
[White  76] .   Within  the  ACSES  project  a  major  effort  was  directed  at 
implementing  small  subsets  of  a  number  of  conventional  languages  [Wilcox 
73];  the  resulting  table-driven  compiler  family  produces  excellent  and 
extensive  diagnostics  [Davis  75,  Tindall  75]  but  it  definitely  exceeds 
PLATO's  processing  capabilities  and  it  has  thus  been  more  or  less  abandoned. 

Implementations  of  standard  languages  on  PLATO  suffer  from  the 
fact  that  their  interpretive  execution  usually  requires  a  massive  amount 
of  character  manipulation.   The  customary  postfix-based  expression  eval- 
uators  are  necessarily  quite  time-consuming  to  run  and  thus  severly  limit 
the  amount  of  numerical  processing  which  such  an  implementation  can  support. 

The  lessons  described  in  this  report  attempt  a  different  approach 
to  supporting  advanced  programming  instruction  on  PLATO.   The  author  lan- 
guage TUTOR  [Sherwood  77a]  supplies  the  compute  statement  which  will  compile 


2 
and  evaluate  a  characterstring  conforming  to  TUTOR' s  expression  syntax 
very  efficiently.   Additionally,  a  define  statement  permits  a  static 
(lesson-compile- time)  declaration  of  names  and  functional  expressions; 
those  names  and  functions  are  then  recognized  in  compute  expression 
elaborations.   It  is  thus  feasible  to  support  a  language  in  a  PLATO 
lesson,  as  long  as  that  language  uses  predefined  names  and  conforms  to 
TUTOR's  expression  syntax.* 

Sherwood  [77b]  has  already  demonstrated  on  PLATO  III  that  a 
minilanguage  for  quick  curve  plotting  can  be  defined  and  supported  in 
this  fashion.   This  report  will  show  a  number  of  much  more  complex 
applications,  mostly  in  data  structure  manipulation  and  systems  pro- 
gramming, which  can  be  efficiently  realized  by  a  suitable  minilanguage 
in  the  TUTOR  style. 

The  mini  programming  systems  described  in  this  report  cannot 
make  any  attempt  at  program  verification.   They  provide  only  a  simulation 
setting  in  which  a  particular  problem  solution  can  be  viewed  in  operation. 
Obvious  bugs  cause  execution  to  terminate,  but  subtle  logical  error 
diagnosis  is  left  up  to  the  student.   While  this  is  not  satisfactory 
if  the  goal  of  PLATO  usage  is  independence  from  any  human  instructor, 
the  lessons  have  still  proven  to  be  a  useful  device  to  accompany  conven- 
tional instruction;  all  the  mini  programming  systems  have  been  used  in 
courses  on  Operating  System  Design  and  Information  Structures  (CS  323  and 
CS  321  in  spring  and  summer  1976) . 

The  report  is  intended  to  serve  three  purposes:  First,  the 
minilanguages  are  introduced  to  show  what  minimal  settings  are  really 
only  required  to  practice  complex  concepts  such  as  tree  manipulation  or 


*  This  syntax,  although  exceptionally  close  to  mathematical  notation,  un- 
fortunately gives  multiplication  precedence  over  division  and  is  thus 
not  easily  exploited  to  support  standard  languages. 


synchronization  mechanism  implementation.   This  aspect  of  the  report  should 
be  useful  for  computer  science  instruction,  whether  or  not  PLATO  is  used. 
(One  of  these  minilanguages  has  been  implemented  in  Ulm  on  a  conventional 
computer  system  [Schloerer  78]). 

Second,  in  presenting  application  examples  it  is  hoped  that 
these  lessons  become  a  standard  tool  in  the  repertoire  of  those  teaching 
the  courses  mentioned  above.   This  author  believes  that  the  simulations 
demonstrate  some  difficult  concepts  a  lot  more  convincingly  then  a  black- 
board discussion  would. 

Third,  parts  of  these  lessons  are  quite  useful  for  development 
of  new  lessons.   It  was,  for  example,  very  easy  to  construct  a  lesson  to 
provide  a  minilanguage  for  tree  manipulation  once  the  basic  mini  program- 
ming system  was  completed.   The  filing  system  module  has  even  been  employed, 
with  minimal  effort,  in  two  new  lessons  (on  lesson  structure  design  and 
on  Nassi-Shneiderman  [73]  flowcharts)  which  do  not  support  minilanguages. 
The  implementation  notes  in  this  report  are  intended  for  experienced 
PLATO  authors;  together  with  the  code  of  the  lessons  themselves  they  can 
perhaps  guide  and  encourage  others  to  construct  more  mini  programming 
systems . 


THE  MINI  PROGRAMMING  SYSTEMS 

1.   csmini 

1 . 1  Purpose 

csmini  is  a  mini  programming  system  in  which  small  recursive 
algorithms  can  be  studied.   Since  the  PLATO  terminal  offers  excellent 
graphics  facilities,  the  minilanguage  is  designed  for  curve-plotting 
applications.   Following  Wirth  [76],  recursively  defined  curves  can  be 
easily  realized. 

For  a  PLATO  author,  csmini  should  serve  as  a  model  implementation 
of  a  small  programming  system.   Especially  the  data  structure  definitions 
and  the  overall  design  of  the  lesson  are  extensively  documented  and  con- 
structed so  as  to  be  easily  modified.   The  parts  of  the  programming  system  - 
filing  system,  editor,  and  execution  simulator  -  have  merely  been  copied  and 
slightly  adapted  for  the  other  lessons  described  in  this  report. 

1. 2  Lesson  structure  and  design  principles 

The  programming  system  consists  of  a  filing  system,  an  editor, 
an  execution  simulator,  and  a  help  sequence  (see  figure  1.1,  the  figure  was 
developed  using  csdesign) . 

The  filing  system  maintains  a  catalog  of  systems,  each  occupying 
one  record  in  a  disk  dataset.   The  filing  system  is  entered  from  and  returns 
to  the  table  of  contents  of  the  lesson.   All  users  may  read,  write,  and 
delete  systems  in  the  catalog.   Each  system  consists  of  a  set  of  global 
variables  and  a  workspace  (a  collection  of  one  or  more  programs);  a  system 
is  accompanied  by  a  title  for  the  catalog  and  a  brief  abstract.   Using  the 
utility  lesson  csminiadm,  a  system  may  be  made  read-only  (indicated  by 
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Figure  1.1:   Standard  Lesson  Structure 
(lesson  csdesign) 


a"*"  in  the  title  listing  of  the  catalog;  see  figure  1.2).   Therefore  a 
lesson  author  or  instructor  can  supply  a  certain  number  of  permanent 
examples  for  the  use  of  the  lesson.   Normally,  systems  are  password  pro- 
tected:  passwords  must  be  supplied  upon  any  access  to  a  system  which  is  not 
read-only.   Therefore  a  group  of  students  may  be  assigned  a  common  problem 
to  solve  individually. 

Following  a  suggestion  made  by  John  Risken  (Control  Data  Cor- 
poration), special  entry  units  to  the  lesson  permit  a  choice  of  datasets 
(mostly  for  knowledgeable  authors)  or  a  preselected  dataset  other  than  the 
standard  dataset  created  by  this  author  (mostly  for  external  user  groups) . 
The  available  read-only  examples  in  minif ile  (the  standard  dataset  for 
csmini)  consist  of  various  implementations  for  the  space-filling  Hilbert-, 
Sierpinski-,  and  W-  curves  [Wirth  76]  (see  figure  1.2). 

The  workspace  editor  operates  on  the  directory  of  programs  in  the 
workspace.   It  is  entered  from  and  returns  to  the  table  of  contents  of  the 
lesson.   New  programs  may  be  added  to  the  directory  and  existing  programs 
can  be  changed  or  deleted.   (In  designing  the  lesson  sequence,  emphasis  was 
placed  on  efficiency,  self -documentation,  and  simplicity.   The  programming 
systems  are  complete  for  each  application,  but  rudimentary.   This  motivates, 
for  example,  the  absence  of  copy  and  rename  features  in  the  workspace  direct- 
ory editor) . 

The  program  editor  is  used  to  create  and  change  a  program.   It  is 
entered  from  and  returns  to  the  workspace  editor,  and  it  operates  line 
oriented  on  one  program  at  a  time.   Key  to  a  simple  execution  simulator  is 
the  fact  that  the  program  editor  is  syntax  controlled:   it  permits  only  the 
construction  of  syntactically  correct  programs.   This  task,  however,  is 
facilitated  by  an  appropriate  design  of  the  minilanguage.   In  particular, 
the  minilanguage  must  be  line  oriented  and  it  does  not  contain  compound 
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Figure  1.2:   Catalog  Entries 
(lesson  csmini) 


statements. 

Each  statement  consists  of  a  keyword,  which  the  editor  expands 

once  the  unique  first  key  is  pressed,  and  perhaps  parameters  such  as  an 

expression,  for  which  the  editor  prompts  once  the  keyword  is  accepted. 

Possible  statement  keywords  are  displayed  on  the  editor  page  (see  figure 

1.3). 

The  editor  treats  a  program  as  two  concurrent  stacks  of  program 

lines  (see  figure  1.4). 

Initially  no  program  lines  are  saved.   New  lines  are  added 
at  the  cursor,  i.e.,  pushed  onto  the  program  stack.   On  each 
line  the  normal  PLATO  EDIT  key  facility  is  available.   The 
SHIFT-HELP  key  erases  (pops  and  discards)  the  last  line  from 
the  program  stack. 

The  BACK  key  moves  the  cursor  back  one  line,  i.e.,  the  last 
line  is  popped  from  the  program  stack  and  pushed  onto  the  save 
stack.   The  NEXT  key  reserves  this  procedure.   It  is  thus  possible 
to  insert  and  delete  lines  inside  the  program;  but  not  to  change 
the  order  of  lines  without  rewriting  some  text. 

Program  size  is  essentially  unlimited  (all  programs  together  share 
the  keyword  and  parameter  areas  in  the  workspace)  but  the  display  on  the 
PLATO  terminal  screen  establishes  an  esthetic  limit  of  about  20  statements 
per  program. 

Parameter  string  length  (again  mostly  for  display  layout  reasons) 
is  limited  to  about  30  characters.   Due  to  the  necessary  complexity  of  some 
definitions  this  string  length,  when  expanded  by  the  TUTOR  compute  statement, 
seems  to  approach  the  limits  of  the  TUTOR  expression  processor. 
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Figure  1.3:   Program  Editor 
(lesson  csmini) 
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The  execution  simulator  is  given  a  program  name  and  a  parameter 
value  to  start  execution,  in  a  workspace;  any  program  can  serve  as  a  main 
routine.   The  execution  simulator  is  entered  from  and  returns  to  the  work- 
space editor.   Just  prior  to  execution,  the  values  for  the  global  variables 
and  details  of  the  halt  condition  can  be  set  up. 

Execution  proceeds  on  a  statement  by  statement  basis.   Continu- 
ous execution  with  a  number  of  monitoring  facilities  is  also  available: 
Once  continuous  execution  is  selected,  a  keypress  will  stop  it  (but  since 
the  PLATO  system  queues  output,  this  visual  interruption  is  quite  imprecise) , 
A  breakpoint  expression  can  be  dynamically  introduced  which  is  evaluated 
prior  to  each  statement  and  which,  when  true,  interrupts  execution.   Sym- 
bolic values  can  be  employed  to  make  breakpoint  expressions  quite  powerful: 

rtn   ...  the  current  program  name, 
loc   ...  the  upcoming  statement  number. 
nest  ...  the  current  number  of  nested  calls, 
halt  . . .  the  condition  is  true  if  the  upcoming  statement 
keyword  was  flagged  prior  to  execution. 

Additionally,  global  and  current  local  variables  may  be  tested.   All  tests 
are  combined  into  an  expression  with  the  usual  TUTOR  syntax.   The  expression 

rtn  =  'seek'  $and$  nest  >  3  $or$  loc  =  2 
will  interrupt  whenever  statement  2  of  a  routine  is  about  to  be  executed, 
or  before  each  statement  of  routine  'seek'  at  a  nesting  level  greater  than 
3.   (Thanks  to  the  TUTOR  compute  command,  the  implementation  of  this  very 
powerful  control  feature  is  quite  simple  and  efficient).   Other  debugging 
facilities  are  a  current  statement  display,  as  well  as  a  non-assignment 
expression  evaluator  which  permits  inspection  of  all  current  values. 

HELP  is  available  throughout  the  lesson.   However,  the  sequence 
of  lessons  was  designed  to  augment  instruction,  not  to  replace  it.   Each 
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lesson  thus  provides  a  help  sequence  which  will  discuss  usage  of  the 
lesson,  and  perhaps  review  the  illustrated  application,  but  which  cannot 
stand  alone. 

For  csmini,  HELP  pages  explaining  usage  are  connected  to  the 
workspace  directory,  the  program  editor,  and  the  execution  simulator. 
Further  pages  explain  the  minilanguage.   Additionally,  all  pages  can  be 
read  in  sequence.   As  figure  1.1  illustrates,  all  HELP  pages  are  accessible 
at  all  points  in  the  lesson  by  means  of  TERM-operations  and  a  table  of 
contents  of  the  HELP  pages.   csmini  is  connected  to  the  standard  computer 
science  service  lessons  [Friedman  76] • 

1. 3  The  Minilanguage 

The  minilanguage  for  csmini  permits  recursive  subroutine  calls, 
computation,  and  plotting.   It  was  designed  to  be  extremely  simple  to 
learn,  easily  verified  with  a  line  oriented,  syntax  controlled  program 
editor,  and  efficiently  executed  with  the  TUTOR  compute  command  and  a 
suitable  set  of  define  names  and  functions.   These  objectives  eliminated 
a  number  of  otherwise  desirable  convenient  language  features,  but  it  was 
felt  that  in  this  extremely  restricted  setting  their  absence  would  not 
distract  from  the  concept  to  be  illustrated  by  the  lesson.   The  following 
statements  are  available: 

CALC  expression 

THE  TUTOR  expression  (which  would  usually  include 
assignment)  is  evaluated. 


EXIT 


Subroutine  execution  is  terminated.   EXIT  from  the 
main  routine  returns  control  from  the  execution 
simulator  to  the  workspace  editor. 
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IF 


JUMP 


PLOT 
PLOT 


SUB 


expression 

The  TUTOR  expression  is  evaluated:   if  it  is  true 
(-1) ,  the  next  statement  is  executed,  otherwise  it 
is  skipped, 
expression 

Lines  in  a  program  are  consecutively  numbered  from 
zero.   The  TUTOR  expression  in  this  statement  deter- 
mines the  line  number  of  the  next  statement  to  be 
executed. 

up  (expression,  expression) 
down  (expression,  expression) 

The  program  draws  on  the  (0  :  511,0  :  511)  PLATO 
terminal  screen.   This  statement  moves  the  pen 
to  the  indicated  point,  possibly  drawing  a  line, 
program  name:   expression 

The  designated  program  is  called  as  a  subroutine 
with  the  indicated  parameter  value. 


The  expressions  involve  literal  constants,  variables,  and  other 
defined  names.   All  values  are  integers;  expressions  follow  TUTOR  syntax. 
Since  text  interpretation  was  to  be  avoided,  variable  names  can  only  be  as 
follows : 

A...Z         global  variables,  available  to  every  routine 

nesting  level  and  initialized  by  the  user  prior 
to  execution. 
a...z  local  variables,  available  only  to  the  current 

routine  nesting  level  and  initialized  to  zero  when 
a  sub  statement  establishes  a  new  routine  nesting 
level.   The  main  routine  also  has  local  variables. 
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parm  the  parameter  value  of  the  current  routine  call.. 

(Read-only) . 

The  symbolic  values  rtn,  loc,  nest,  and  halt,  as  described  for 
breakpoint  expressions,  are  also  available  (read-only).   Additionally,  the 
vectors  Var(l-26)  and  var (1-26)  can  be  used  to  access  the  global  and  local 
variables. 

1.4  An  example:   Hilbert  curves 

Wirth  [76]  suggests  a  recursive  definition  for  the  Hilbert  curves 
(figure  1.5).   The  main  routine,  which  is  non-recursive,  could  be  coded 
as  follows: 

0  calc        i  ■*=  1,  curve  index 

1  calc        H  *=  512,  plot  increment,  initially 

screen  width 

2  calc        x  <=  y  *=  256,  start  point,  initially  screen 

center 

3  calc        H  *=  H/2,  loop  over  curve  index 

4  plot        up  (X  *=  x  *=  x  +  H/2,    pen  to  start  point 

Y  <=   y  <=  y  +  H/2), 

5  sub         A  :  i,  curve  is  plotted  as  an  A 

segment 

6  if  (i  *=  i  +  1)  <  parm,    parm  is  maximal  index 

7  jump        3,  loop  to  next  curve  index 

8  exit 

Notes: 

(1)  Comments  can  be  appended  to  expressions  following  a 
comma  (a  TUTOR  compute  feature) . 

(2)  The  local  variables  x,  y  of  the  main  routine  monitor 
the  starting  points  of  the  curves. 
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(3)  The  global  variable  H  determines  the  line  segment  length, 
which  is  constant  through  all  segment  routines. 

(4)  The  global  variables  X,  Y  monitor  the  current  pen  position, 


The  recursive  curve  segment  A  is 


0 

if 

parm  <  1, 

1 

exit 

2 

sub 

B  :  parm  -  1, 

3 

plot 

down  (X  «■  X  -  H,  Y) 

4 

sub 

A  :  parm  -  1, 

5 

plot 

down  (X,  Y  <=  Y  -  H) 

6 

sub 

A  :  parm  -  1, 

7 

plot 

down  (X  «=  X  +  H,  Y) 

8 

sub 

D  :  parm  -  1, 

9 

exit 

A  (<  1)  is  just  a  point 
add  a  B  segment 
add  an  A  segment 
add  an  A  segment 
add  a  D  segment 


A  plots,  from  top  right  to  bottom  right,  three  sides  of  a  square,  recursively 
calling  other  segments  (with  a  lower  index)  at  each  vertex.   B,  C,  and  D 
are  congruent  to  A  but  rotated  90°  each. 
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Figure  1.5:   Plotting  Hilbert  Curves 
(lesson  csmini) 
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1 . 5  Implementation  notes 

The  filing  system  operation  is  discussed  in  Section  2.4. 
Interesting  for  the  interface  is  only  the  fact  that  the  available  data 
regions  (student  variables  and  storage)  are  described  as  two  areas: 

fileQ  saved  as  a  workspace  by  the 

filing  system. 

bank()  not  touched  by  the  filing  system. 

Customarily,  if  storage  is  used,  it  would  be  described  as 
fileQ  and  bank()  refers  to  all  student  variables  (with  the  exception 
of  those  used  for  computer  science  lesson  conventions  [Friedman  76]); 
if  storage  is  not  used,  fileQ  and  bank()  would  have  to  split  the 
student  variables. 

For  the  programming  systems,  fileQ  generally  contains  the 
following  areas: 

global  variables         usually  as  20  bit  segments. 

special  purpose  area     contains  at  least  some  pointers 

delimiting  the  text-and  keyword- 
areas  in  use. 

code  segment  descriptors   describing  the  routines  in 

the  workspace. 

statement  headers        containing  the  statement  keywords 

and  possibly  pointers  to  text. 

text  area  for  expressions  belonging  to 

statements. 

Recursive  languages  locate  their  local  variables  as  a  stack 
of  activation  records  in  bankQ .  The  active  set  of  variables  is  in  a 
fixed  position  (to  improve  performance) ,  a  routine  call  then  involves 


some  shifting  of  local  variable  values  to  be  inactivated.   To  improve 
execution  speed  all  variables  exist  and  are  stacked,  not  only  variables 
actually  referenced;  routine  calls  can  still  be  nested  aobut  12  deep. 
Additionally,  bank()  contains  some  auxiliary  variables. 

The  following  strategies  are  used  to  obtain  write-and  sub- 
script-range protection  while  using  the  compute  statement: 

read-only  values  are  defined  as  0+location;  thus  the 
location  may  be  inspected  but  not  modified. 

arrays  such  as  Var(i)  alias  A..Z  are  defined  as  follows:* 
Var(i)  -  gbl(i+i[i  <1  $or$  i  >  26]) 
gbl()  is  a  segment  over  which  the  names  A..Z  are  defined 
in  positions  1..26.   This  name  is  available  but  (hopefully) 
unknown  to  the  student.   The  subscript  for  gbl  above  is  0 
whenever  the  subscript  i  for  Var  is  out  of  range;  thus, 
compute  will  then  automatically  produce  a  detectable 
execution  error. 

The  following  strategy  for  the  up()  and  down()  functions  in  plotting 
is  also  typical: 

up(i,j)  =  0(gblplot(53)  «■  i)(gblplot(54)  •"  j) 
gblplotQ  are  two  temporary  variables  which  thus  receive 
the  target  point  of  the  plot  statement  with  one  execution 
of  the  compute  statement. 


*  Much  of  this  should  now  be  available  as  TUTOR  arrays. 
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This  trick  requires  no  explicit  text  manipulation  during  the 
simulation  and  is  thus  a  very  efficient  way  to  gather  the  data  necessary 
for  the  plot  statement. 

A  workspace  mostly  contains  an  area  for  statements  consisting 
of  an  area  for  statement  headers  and  an  area  for  expression  text.   State- 
ments for  one  routine  appear  consecutively  in  each  of  these  areas. 

A  statement  header  contains  a  code  for  the  statement  keyword  and 
(if  required)  a  pointer  to  the  first  word  of  text  belonging  to  the  state- 
ment and  a  count  of  the  text  length  in  characters.   The  pointer  is  relative 
to  the  first  text  word  in  the  routine  to  simplify  compaction  of  all  areas. 
Among  the  text  words  is  the  pointer  required  for  the  TUTOR  compute  state- 
ment.  Statement  headers  are  packed  as  6-bit  codes. 

A  code  segment  descriptor  holds  a  routine  name,  an  absolute 
pointer  to  the  first  statement  header  for  this  routine,  an  absolute  pointer 
to  the  first  text  word,  and  counters  for  the  number  of  statements  defined 
in  the  routine  and  the  number  of  text  words  used.   This  information  is  used 
to  monitor  jumps  during  execution,  and  it  is  maintained  by  the  workspace 
and  program  editor. 

The  statement  area  is  compacted  when  a  code  segment  is  deleted 
and  the  pointers  in  the  remaining  code  segment  descriptors  are  updated 
accordingly.   When  a  code  segment  is  newly  added  or  edited,  it  is  always 
positioned  at  the  end  of  the  statement  area  —  when  the  area  is  almost 
full,  editing  an  existing  segment  may,  unfortunately,  become  impossible. 

This  policy  was  believed  to  simplify  text  management  for  the 
editor  (figure  1.4):   in  order  to  save  the  current  statement,  it  is  shifted 
forward  to  the  end  of  the  statement  area.   Thus  the  program  grows  forward 
in  the  statement  area  and  the  saved  statements  grow  backward. 
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An  attempt  was  made  to  make  the  code  of  the  editor  easy  to 
extend:   two  routines,  getop  and  getaux  are  employed  to  obtain  a  state- 
ment keyword  and  a  parameter  expression,  respectively.   Using  the  TUTOR 
store  statement,  an  incoming  expression  is  evaluated:   syntax  errors  can 
thus  immediately  be  recognized  and  rejected  (only  indexing  errors  and 
mathematical  exceptions  must,  of  course,  be  accepted). 

The  execution  simulator,  finally,  is  straight-forward:   once 
global  variables  and  the  halt  condition  (the  latter  part  of  bank())  have 
been  initialized,  the  simulation  proceeds  as  a  continuous  loop.   Inter- 
ruptions through  explicit  keys  or  the  breakpoint  expression  are  considered 
first.   Next,  the  statement  keyword  code  is  used  to  select  one  of  a  number 
of  executors.   Finally  the  loop  continues  with  location  counters  updated,  etc, 
The  executors  share  an  expression  evaluator  —  a  compute  statement  with  some 
error  analysis. 
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2 .   csminiadm 

2.1  Purpose 

The  programming  systems  such  as  csmini ,  cstrees,  etc.,  employ 
a  combination  of  datasets  and  TUTOR  common  storage  to  realize  their  filing 
systems,   csminiadm  is  used  to  control,  expand,  and  perhaps  repair  the 
catalog  structure  of  the  filing  systems;  csminiadm  is  absolutely  ignorant 
of  the  contents  of  a  system,  i.e.,  of  the  interior  structure  of  a  record 
in  the  disk  dataset.   A  copy  of  Dave  Eland's  variable  editor  from  PLATO 
lesson  cslibrary  [Friedman  76]  is  provided  to  enable  the  knowledgeable 
user  to  inspect  and  possibly  alter  this  structure  also. 

2 . 2  Design  considerations 

The  filing  system  for  the  lessons  in  this  sequence  was  designed 
to  be  generally  usable,  cheap  in  resource  consumption,  efficient  and 
flexible.   In  order  to  support  various  applications,  the  design  should 
be  ignorant  of  the  contents  and  size  of  a  system  (disk  record) .   As  a 
source  of  teaching  examples,  the  filing  system  must  provide  catalog  title 
and  abstract  services. 

Long-term  data  storage  on  PLATO  is  accomplished  with  a  disk 
data-set  -  use  of  such  a  dataset  is  permitted  only,  however,  if  reasonable 
limits  are  placed  on  the  amount  of  disk  access  required. 

In  order  to  make  browsing  in  the  catalog  a  cheap  operation, 
catalog  titles  and  abstracts  are  maintained  in  common  storage.   Each  lesson 
in  the  sequence,  however,  operates  with  its  own  catalog;  each  lesson  is  thus 
independent  of  the  other  lessons.   As  a  catalog  grows  (more  permanent  ex- 
amples are  added  or  a  large  group  of  students  is  assigned  a  programming 
exercise),  catalog  and  dataset  space  must  be  expanded.   It  should  also  be 
shortened  once  a  programming  assignment  is  completed.   Since  the  catalog 


22 


data  structure  is  fairly  sophisticated,  a  utility  program  (csminiadm)  must 
aid  the  instructor  or  author  in  these  tasks. 

Common  storage  in  the  PLATO  system  is  lesson  specific.   (This 
system  was  designed  before  name  sets  and  the  commonx  command  became  available.) 
In  order  to  merely  maintain  one  utility  program  for  all  lessons,  only  one 
common  (physically  located  in  csminiadm)  is  shared  by  all  lessons.   The 
catalog  is  saved  in  the  last  few  records  of  each  dataset  used  for  a  filing 
system  and  is  read  into  the  common  as  needed.   Exclusive  access  to  a  catalog 
for  update  operations  is  defined  as  reserving  exclusive  use  of  a  common 
with  the  TUTOR  reserve  command. 

Since  it  is  fairly  unlikely  that  several  lessons  in  this  sequence 
are  used  simultaneously  on  the  PLATO  system,  this  solution  seems  a  reasonable 
compromise  between  resource  consumption,  (i.e.,  disk  access  and  memory 
requirements)  and  the  Control  Data  Corporation  requirement  of  automating 
or  at  least  simplifying  lesson  -dataset-  maintenance. 

The  fact  that  each  dataset  contains  its  own  catalog,  and  that 
each  lesson  has  entry  points  which  permit  use  of  other  than  the  standard 
datasets,  additionally  allows  an  independent  group  of  users  to  access  a 
lesson  with  a  private  catalog  of  examples  and  files.   An  instructor  must 
provide  a  dataset,  initialize  it  using  csminiadm,  and  route  his  student 
records  appropriately.   (The  idea  is  due  to  John  Risken) . 

2 . 3  Lesson  structure 

Access  to  the  lesson  csminiadm  is  available  to  any  user  who 
can  attach  (i.e.,  specify  on  the  lesson's  entry  page)  a  dataset  and  who 
knows  it's  codeword.   Once  this  information  is  provided,  it  is  assumed  that 
the  user  basically  understands  what  he  wants  to  do  using  csminiadm.   A  few 
HELP  pages  provide  information  on  the  services  and  the  catalog  structure. 
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The  lesson  operates  in  two  modes.   In  non-exclusive  mode,  the 
catalog  of  the  attached  dataset  can  be  manipulated  in  the  same  fashion  as 
in  any  other  lesson  using  the  filing  system.   Access  to  the  catalog  is 
only  temporarily  exclusive  and  any  modifications  (adding  or  deleting  system 
descriptions)  may  be  permanent. 

In  contrast,   the  lesson  can  also  be  operated  with  exclusive 
access  to  the  attached  dataset  and  catalog.   In  this  case,  no  other  user 
of  the  lesson  sequence  can  access  any  filing  system  until  the  user  of 
csminiadm  has  again  explicitly  updated  or  aborted  the  catalog  and  released 
common  storage. 

In  non-exclusive  mode,  system  descriptions  may  be  viewed  as  a 
student  would  see  them  (additionally,  parameters  such  as  the  password  are 
also  shown).   Systems  can  be  deleted,  fetched  from  disk  (but  no  further 
options  for  system  inspection  exist),  and  added.   A  system  is  deleted  by 
removing  its  catalog  description  from  common;  the  actual  system  occupies 
a  disk  record  and  is  only  over-written  once  a  new  system  is  written  into 
the  same  disk  record.   (Especially  in  exclusive  mode,  catalog  manipulation 
errors  can  thus  sometimes  be  corrected.)   When  a  system  is  added,  it  can 
be  made  read-only.   The  capability  to  fetch  systems  from  disk  and  to  add 
systems  to  the  catalog  and  dataset  is  intended  for  copying  purposes  mostly. 

In  exclusive  mode,  the  catalog  may  also  be  manipulated  as  de- 
scribed above.   Additionally,  the  catalog  parameters  (passwords,  title 
lengths,  disk  record  numbers,  protection  bits,  etc.)  can  be  viewed  and 
modified  for  the  entire  catalog  at  once.   The  catalog  for  a  new  dataset 
must  be  initialized;  existing  dataset  catalogs  can  be  adapted  to  allow 
extension  and  shortening  of  a  dataset.   Defined  names  of  the  csminiadm  les- 
son are  specified  with  a  TUTOR  define  student  command,  (knowledgeable  users 
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can  thus  explicitly  modify,  and  perhaps  repair,  any  parameter);  similarly^ 
a  copy  of  Dave  Eland's  variable  editor  from  cslibrary  permits  unstructured 
access  toall  variables  and,  in  particular,  to  a  system  fetched  from  disk. 

Initialization  of  a  catalog  consists  of  marking  unused  all  avail- 
able disk  records  in  the  catalog,  and  of  marking  the  description  area  as 
empty.   The  size  of  a  catalog  in  disk  records  is  a  function  of  the  dataset 
parameters: 

40  *  (records  in  the  dataset) 
40  +  (words  per  record) 

This  is  truncated  to  an  integral  value  and  bounded  by  the  size  of  common 
storage.   (40  marks  the  average  size  of  a  description.) 

The  catalog  is  stored  at  the  end  of  the  dataset;  this  avoids  having 
to  relocate  descriptions  when  the  size  of  the  dataset  changes  -  only  the 
catalog  itself  must  be  moved  to  a  new  position  prior  to  shortening  or 
subsequent  to  lengthening  the  dataset. 

Expansion  of  a  catalog  requires  that  the  user  first  physically  extends 
the  PLATO  dataset  (currently  this  preserves  contents),  and  then  uses  csminiadm. 
The  catalog  is  retrieved  from  its  old  position,  now  inside  the  dataset, 
expanded,  and  stored  at  the  end  of  the  extended  dataset.   The  old  size  of  the 
dataset  in  PLATO  parts  of  seven  blocks  of  320  words  each  must  be  provided  by 
the  user. 

Reduction  of  a  catalog  requires  use  of  csminiadm  to  remove  systems 
which  no  longer  fit  in  a  shortened  dataset,  to  decrease  the  physical  catalog 
size,  and  to  store  the  catalog  in  that  position  in  the  dataset  which  will 
become  its  end  once  it  is  shortened.   Then  the  PLATO  dataset  is  physically 
shortened  (currently  this  preserves  contents) .   (Disk  space  is  filled  with 
systems  from  the  beginning  of  a  dataset.   A  few  copy  operations  are  perhaps 
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required  to  free  scattered  disk  space  before  a  catalog  is  reduced.) 

Exclusive  access  to  a  catalog  must  be  explicitly  terminated  - 
either  by  storing  and  thus  updating  the  modified  catalog,  or  by  simply 
destroying  the  common  copy  of  the  modified  catalog. 
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2. 4   Implementation  notes  for  the  filing  systems 

The  common  storage  used  as  a  system  directory  has  the  following 
layout : 

name  of  the  attached  dataset 
one  control  word: 

number  of  systems  in  use 
allowed  number  of  systems* 
directory  (common)  size* 
fixed  part  of  system  descriptors: 
pointer  to  variable  part 
length  of  title 
length  of  abstract 
disk  block  number 
protection  bit 
text  area  (filled  from  the  end  forward): 
variable  part  of  the  descriptors: 
title 
password 
abstract 

A  bit  map  is  inserted  into  the  fixed  descriptor  part  area  and 
indicates  which  disk  blocks  are  in  use. 


*  Recomputed  to  allow  for  expansion  and  shortening, 
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The  catalog  title  and  abstract  display  mechanism  (part  of  each 
lesson)  is  straight-forward:  the  common  is  reserved  for  exclusive  access; 
if  necessary  the  correct  directory  is  loaded  from  the  desired  dataset; 
titles  and  abstracts  can  be  viewed.   An  imain  unit  and  a  finish  unit  are 
employed  to  return  an  updated  directory  to  the  dataset  if  deletions  or 
additions  were  made. 

If  a  system  is  added,  it  is  saved  into  an  available  disk  block. 
The  file()  area  is  then  used  to  construct  a  title  and  an  abstract.   If  the 
user  does  not  back  out,  title  and  abstract  are  added  to  the  catalog,  and 
the  disk  map  is  updated.   In  any  case,  file()  is  restored  from  disk.   This 
process  is  a  compromise  between  minimizing  the  number  of  variables  necessary 
for  use  of  the  filing  system  (exactly  one  word,  located  among  the  computer 
science  linkage  variables)  and  keeping  the  number  of  disk  accesses  small. 
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3.   cstrees 

3. 1  Purpose 

Linked  lists,  and  in  particular  trees  represented  as  linked 
lists,  are  datastructures  used  in  many  programming  applications.   Knuth  [73] 
describes  numerous  fundamental  algorithms  for  list  manipulation,  tree 
representation,  tree  traversal,  etc.   PLATO  lessons  are  being  developed 
(consult  [Friedman   78])  which  permit  manual  list  node  manipulation  and 
graphically  illustrate  the  results. 

cstrees  provides  a  version  of  the  csmini  programming  system 
suited  primarily  to  programming  various  tree  manipulation  algorithms. 
During  execution  of  an  algorithm,  allocated  nodes  are  displayed  on  the 
PLATO  terminal  screen  and  the  dynamic  behaviour  of  their  links  is  shown. 

Elaborate  use  of  the  TUTOR  define  statement  allowed  a  very 
efficient  implementation  of  the  execution  simulator  with  the  TUTOR  compute 
statement,   cstrees  was  completed  in  about  three  days  in  spite  of  the 
complexity  of  the  managed  datastructures.   The  steps  of  the  implementation 
process,  which  consisted  of  modifying  a  copy  of  csmini,  are  explained  in 
the  implementation  notes  below. 

3. 2  Lesson  structure 

cstrees  uses  the  exact  same  structures  as  does  csmini:   the  pro- 
gramming system  consists  of  a  filing  system,  an  editor,  an  execution  sim- 
ulator, and  a  help  sequence  (see,  again,  figure  1.1). 

The  filing  system,  workspace  and  program  editor  are  copied  from 
csmini;  the  program  editor  is  adapted  to  control  the  slightly  altered  mini- 
language.   The  help  sequence  is  copied  form  csmini;  new  pages  are  included 
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to  document  the  modified  minilanguage. 

The  available  read-only  examples  in  treef ile  (the  standard 
dataset  for  cstrees)  consist  of  various  implementations  of  binary  tree 
creation,  traversal,  and  deletion  algorithms,  and  of  algorithms  for 
the  maintenance  of  sorted  binary  trees. 

The  execution  simulator  supports  the  same  control  facilities 
as  does  csmini.   When  new  nodes  are  allocated,  the  execution  simulator 
requests  a  screen  position  from  the  user.   The  position  may  be  supplied 
through  the  PLATO  touch  panel  or  through  a  more  conventional  cursor 
implementation  with  the  arrow  keys.   Once  positioned,  a  node  can  no  longer 
be  moved  on  the  screen.   (While  a  "move  node"  feature  would  not  pose  great 
technical  problems,  its  absence  simplifies  execution  supervision  and  en- 
courages algorithm  understanding  -  only  a  knowledgeable  student  can  produce 
a  pretty  picture.) 

3.3  The  minilanguage 

The  minilanguage  for  cstrees  permits  recursive  subroutine  calls, 
computation,  node  allocation,  link  manipulation,  visitation,  and  deletion. 
The  objectives  in  language  design  stated  for  csmini  still  apply.   This 
produced  somewhat  obscure  features  such  as  the  "input"  and  "newnode"  defined 
names.   In  the  small  applications  envisioned  for  the  cstrees  system  it 
should  still  be  possible  to  write  clean  code,  however. 

The  following  statements  are  available  and  identical  in  usage 
to  csmini: 

CALC  expression 

EXIT 

IF  expression 

JUMP  expression 
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SUB 


program  name:   expression 


The  following  new  statements  apply  to  node  manipulation: 


FREE 


GET 


READ 


VISIT 


expression 

The  value  of  the  TUTOR  expression  must 
identify  an  existing  node,  which  is 
destroyed  (i.e.,  vanishes  from  the  screen), 
expression 

A  new  node  is  created  (and  must  be  positioned 
on  the  screen) .   Its  identification  (actually 
a  positive  integer  value)  is  assigned  to  the 
defined  name  "newnode".   Then  the  TUTOR 
expression  is  evaluated.   The  expression  would 
normally  assign  "newnode"  to  some  variable 
or  node  field, 
expression 

A  statement  to  provide  input  from  the  user,  e.g., 
to  provide  information  for  an  entry  into  a  sorted 
tree.   An  integer  value  is  accepted  from  the  user 
and  assigned  to  the  defined  name  "input".   Then 
the  TUTOR  expression  is  evaluated.   The  expres- 
sion would  normally  assign  "input"  to  some  vari- 
able or  node  field, 
expression 

The  value  of  the  TUTOR  expression  must  identify 
an  existing  node  which  is  high-lighted  on  the 
screen.   The  statement  is  intended  to  symbolize 
the  coroutine  to  a  tree  traversal  algorithm. 
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The  expressions  involve  constants,  variables  and  fields  of  nodes. 
All  values  are  essentially  integers;  expressions  follow  TUTOR  syntax,  where 
a  functional  notation  identifies  node  fields.   As  in  csmini,  we  have  the 
global  variables  A  . .  Z  alias  Var  (1)  . .  Var  (26) ,  for  each  nesting  level 
the  local  variables  a  . .  z  alias  var  (1)  . .  var  (26) ,  the  read-only  routine 
call  parameter  value  parm,  and  the  execution  control  read-only  defined  names 
rtn,  loc,  nest,  and  halt. 

Additionally,  the  READ  statement  supplies  a  value  for  the  read- 
only defined  name  input,  and  the  GET  statement  maintains  the  newnode 
identification. 

Nodes  have  the  following  fields: 

info   (p)      information  field,  an  integer. 

ltag   (p)      left  tag,  a  bit. 

llink  (p)      left  link,  should  be  a  pointer. 

rtag   (p)      right  tag,  a  bit. 

rlink  (p)      right  link,  should  be  a  pointer. 

When  a  node  is  created  all  fields  are  0,  meaning  "false"  for  tags  and 
"nil"  for  pointers.   On  the  screen  (see  fig.  3.1),  a  pointer  is  shown  as 
a  vector  to  the  existing  target  node,  wild  or  nil  pointers  are  absent, 
false  tags  are  black  and  true  tags  orange  squares.   "p"  in  the  definition 
above  may  be  any  TUTOR  expression  yielding  a  meaningful  value.   Normally 
it  would  be  a  node  field  or  variable  which  obtained  its  value  by  assign- 
ment originally  from  newnode.   Access  in  this  fashion  is  read-only. 

Write  access  to  a  node  is  permitted  once  per  expression  (to 
simplify  implementation  of  the  node  animation  mechanism  of  the  execution 
simulator)  through  the  field  names:   winfo,  wltag,  wllink,  wrtag,  wrlink. 
Additionally,  entire  nodes  can  be  accessed  as  node  (p) ,  or  wnode  (p) . 
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Figure  3.1:   Threaded  Binary  Trees 
(lesson  cstrees) 
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It  should  be  emphasized  that  syntax  verification  and  execution 
of  all  expressions  is  performed  with  the  TUTOR  define,  store,  and  compute 
statements.   Suitable  definitions  of  the  node  fields  enable  the  node 
animator  to  recover  all  necessary  information  post-mortem. 

3.4  An  example:   insertion  into  a  preorder  -  sorted  tree 

The  routine  "pre"  is  called  with  parm  pointing  to  a  tree  for  which 
the  node  information  is  sorted  with  respect  to  preorder  traversal.   Input 
is  information  which  was  placed  in  the  node  identified  by  newnode.   This  node 
will  be  linked  into  the  proper  place  in  the  tree.   The  algorithm  is  iter- 
ative, for  a  Nassi  Shneiderman  [73]  flowchart  see  fig.  3.2. 


0 

CALC 

p  <=  parm, 

1 

CALC 

r  *=  rlink  (p) , 

2 

CALC 

1  «-  llink  (p), 

3 

IF 

r  =  0  : 

?and$  1=0, 

4 

JUMP 

14, 

5 

IF 

info  (r)  <  input, 

6 

JUMP 

16, 

7 

IF 

1  =  0, 

8 

JUMP 

12, 

9 

IF 

info  (1)  <  input, 

10 

JUMP 

18, 

11 

CALC 

wrlink 

(newnode)  <=  1, 

12 

CALC 

wllink 

(p)  <=  newnode , 

13 

EXIT 

14 

CALC 

wrlink 

(p)  <=  newnode  , 

15 

EXIT 

16 

CALC 

P  *=  r, 

17 

JUMP 

1 

18 

CALC 

P  «"  1, 

19 

JUMP 

1 

p  f  root  of  the  tree,  initially 

r  t  right  son  of  p  if  any 

1  t  left  son  of  p  if  any 

no  sons? 

yes  -  attach  to  the  right  of  p 

right  son  smaller? 

yes  -  move  down  on  right 

no  left  son? 

yes  -  attach  to  the  left  of  p 

left  son  smaller? 

yes  -  move  down  on  left 

no  -  make  1  right  son  of  input  (  ) 

attach  to  the  left  of  p 

attach  to  the  right  of  p 

p  t  lower  node  in  tree 

p  t  lower  node  in  tree 
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Assumption  of  the  algorithm  is  that  input  is  information  which 
must  be  <  information  in  the  current  node  p.  Input  is  not  compared  to 
the  current  node  information.  Thus,  an  empty  tree  must  have  a  root  node 
with  no  sons.  If  a  node  has  only  one  son,  its  information  is  assumed  to 
be  <  the  node's  own  information,  and  it  must  be  a  right  son.  This  state 
of  affairs  is  used  in  line  5  and  preserved  in  lines  14  and  especially  11/12, 

A  driver  routine  could  be: 


0 

GET 

1 

READ 

2 

GET 

3 

SUB 

4 

IF 

5 

JUMP 

6 

.  .  .  . 

P  *=  newnode, 

input, 

winfo  (newnode)  ■*=  input, 

pre:   P, 

input  4"   0, 

1 


P  +  tree,  empty  root  here, 
obtain  input  and 
place  it  in  new  node, 
now  attach  the  node 
say  0  should  stop  this 


(The  actual  example  compares  preorder  and  inorder  maintenance.) 
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i  n  f  o  (r  i  ght  (p 

true 

i  )      i  nput 
fa  1  se 

p  4=  right  Cp) 

no,  but  lei 

true 

"t  Cp)  =  ni  1 

attach 
left  Cp)  * 

newnode 

no .  but  i n f o  ( 

true 

left)  <  input 
false 

p  *  1  e  ft  (p) 

attach 

right  (new)  4= 
left  Cp) 

left  Cp)  4= 

newnode 

Figure  3.2:   Insertion  Into  Preorder-Sorted  Tree 
(lesson  csflow) 
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3. 5   Implementation  notes 

cstrees  is  implemented  in  much  the  same  way  as  was  csmini . 
The  power  of  the  TUTOR  expression  processor  combined  with  the  define 
statement  permitted  a  very  efficient  implementation  of  the  node  animation 
feature.   The  following  definitions  are  typical: 

info(i)  =  0  +  yinfo(i+i[i  <  1  $or$  i  >  ytop  $or$  yynd(i)  =  0]) 
y  is  used  to  prefix  names  which  are  available  but  (hopefully) 
not  known  to  the  student.   The  info()  field  is  read-only, 
protected  from  subscript  violations,  and  if  the  y-coordinate 
of  the  node,  yynd(),  is  zero,  the  node  —  although  within 
subscript  bounds  —  is  nonexistent.   All  violations  are 
automatically  trapped. 
winfo(i)  =   info(0[yold  «■  info(i)  ]  [yf Id  *=  1]  +  yi  «■  i) 

When  the  info()  field  is  thus  written,  it's  old  value  is 
trapped  into  yold,  an  update  case  is  set  in  yfld,  and  a 
pointer  to  the  modified  node  is  trapped  in  yi  (long  live 
embedded  assignment!)   After  the  compute  statement  is  done, 
the  display  can  thus  be  updated  easily. 

Nodes  are  stored  in  bank(),  they  contain  the  published  fields  and 
the  coordinates  of  the  node  in  the  display.   The  node  storage  is  managed 
dynamically  as  a  stack,  but  (obviously)  without  compaction:   deleted  nodes 
can  be  found  as  described  above.   Speed  is  not  essential,  since  node 
positioning  on  the  screen  is  done  manually,  anyway. 


37 


3. 6   Implementation  guide 

The  following  steps  were  necessary  to  create  cstrees  from  a 
copy  of  csmini: * 

change  the  title  and  page  headers. 

change  knowop,  the  number  of  known  statement  keywords,  adapt 

the  units  putop  (keyword  display) ,  shows tmt   (statement 

display)  getop  (keyword  input  to  the  editor) ,  and  getaux 

(parameter  input) .   The  unit  getplot  (plot  statement 

input)  is  now  obsolete, 
adjust  getexp  and  get  sub  so  that  a  multiple  use  of  winfoQ, 

etc.,  is  rejected, 
define  new  variables  such  as  newnode  and  match  them  with  the 

student  define  set . 
adapt  the  help  pages  —  the  editor  is  now  complete, 
the  initialization  unit  Setup  must  be  corrected  to  reflect 

new  statements, 
the  simulation  unit  Plot  must  be  expanded,  execution  modules 

for  the  new  statements  have  to  be  inserted. 

This  procedure  is  fairly  straight  forward;  csmini  is  commented 
extensively  to  aid  in  this  process.   As  long  as  the  minilanguages  are 
related,  the  task  is  relatively  small;  extensions  to  languages  such  as 
the  next  two  examples  are  more  difficult. 


*  Much  of  the  code  should  be  shared  using  use  statements.   Presently  this 
is  not  done  since  cslibrary  is  also  used. 
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4.   buffering 

4. 1  Purpose 

buffering  is  a  system  programming  application  of  the  csmini 
programming  system.   It  provides  a  setting  in  which  the  student  can 
experiment  with  input-output  supervisors  performing' buff ered  or  unbuffered 
data  transfers  employing  direct  memory  access  hardware. 

buffering  was  the  first  lesson  of  this  sequence.   It's  essential 
techniques  were  subsequently  abstracted  into  csmini.   Simplification  and 
generalization  of  the  filing  system  in  csmini  was  transferred  back  to 
buffering.   The  final  version  now  is  an  adaption  of  csmini  to  a  problem 
in  systems  programming. 

4 . 2  Lesson  structure 

buffering  uses  a  structure  very  similar  to  csmini:   the  pro- 
gramming system  consists  of  a  filing  system,  an  editor,  an  execution 
simulator,  and  a  help  sequence  (fig.  1.1). 

The  filing  system  is  copied  from  csmini.   Examples  are  available 
in  buf ff ile  (the  standard  dataset  for  buffering)  for  buffered  and  unbuffered 
input  and  output  systems. 

The  help  sequence,  in  addition  to  explaining  the  minilanguage , 
discusses  the  application  simulated  by  buffering: 

In  a  third  generation  operating  system,  the  user's  application 
program  is  abstracted  as  follows: 

OPEN  a  file  for  input  or  output; 

L:    GET  BUFFER     full  on  input/empty  on  output; 

COMPUTE  b      with  the  contents  of  the  buffer  b; 

FREE  BUFFER    to  refill  on  input/store  on  disk  on  output; 

JUMP  L 
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The  underlying  computer  is  visualized  as  a  central  processing 
unit  (CPU)  and  a  channel  performing  data  transfers.   The  user's  computation 
takes  "rcomp"  time  units,  while  the  channel  takes  "rdata"  time  units  for  a 
buffer  transfer.   The  channel  may  be  capable  of  interrupting  the  CPU. 

The  student  using  buffering  is  charged  with  programming  the 
input  -  output  supervisor.   The  interface  to  his  system  consists  of  four 
routines:   OPEN  is  invoked   initially  by  the  user  program  and  allocates 
"bufno"  buffers,  the  transfer  direction  is  selectable;  GET  and  FREE  are 
regularly  invoked   by  the  user  program;   INTERRUPT  is  a  routine  invoked 
by  the  channel  upon  completion  of  a  transfer. 

Some  variables  in  the  system  are  shared.   The  filling  and 
emptying  of  the  buffers  is  shown  on  the  screen  by  the  execution  simulator, 
and  the  student's  input  -  output  supervisor  system  should,  of  course, 
operate  correctly  and  efficiently  with  respect  to  buffer  usage,  "busy 
waiting",  etc. 

Since  the  necessary  program  names  are  predefined,  buffering 
combines  the  workspace  and  program  editors  of  csmini  into  one  module  (page) . 
The  program  editor  provides  standard  services. 

The  execution  simulator  is  entered  from  the  table  of  contents  or 
the  program  editor.   First  it  permits  some  initialization  of  values  such 
as  transfer  -  and  computation  speeds,  buffer  number,  etc.   Once  started, 
the  simulator  illustrates  the  input  -  output  activity  within  the  ring  of 
buffers.   The  text  of  the  executing  programs  is  displayed,  one  routine  at 
a  time  (fig.  4.1).   The  breakpoint  execution  control  feature  of  csmini  is 
eliminated;  instead,  execution  proceeds  by  statement,  routine,  or  con- 
tinuously. 

The  program  text  display  can  be  locked  into  a  single  routine. 
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The  student  can  thus  shift  his  attention  and  follow,  for  example,  only 
the  action  of  the  interrupt  handler,  etc. 

buffering  is  an  example  of  a  problem  which  has  (essentially)  only 
one  correct  solution,  and  which  is  difficult  to  be  assigned  in  a  simulation 
experiment  setting  which  should  require  programming  a  solution  to  the  pro- 
blem rather  than  programming  the  entire  experiment.   Furthermore  the 
solution  is  difficult  to  be  completely  verified  automatically.   The  lesson 
provides  the  simulation  setting,  a  problem-oriented  minilanguage  for  the 
solution,  and  avoids  the  task  of  verification.   Instead,  the  student  is 
given  a  simulation  of  his  result,  and  it  is  up  to  him  to  gain  insight,  verify, 
and  perhaps  correct  his  answer.   Only  obvious  bugs  such  as  operations  on 
empty  or  nonexistent  buffers,  input  into  a  full  buffer,  use  of  the  same 
buffer  simultaneously  by  CPU  and  channel,  etc.,  can  be  experimentally 
discovered  by  the  simulator  and  are  signalled  to  the  user. 

4. 3  The  minilanguage 

The  minilanguage  for  buffering  was  designed  with  the  objectives 
of  csmini  in  mind.   It  provides  the  essential  statements  for  the  supervision 
of  a  direct  memory  access  feature,  i.e.,  the  ability  to  solve  the  stated 
problem.   (The  minilanguage,  of  course,  is  not  recursive.) 

The  following  statements  are  available  and  identical  in  usage 
to  csmini: 


CALC 

expression 

IF 

expression 

JUMP 

expression 
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ENABLE 


STARTIO 


The  following  new  statements  apply  to  channel  manipulation: 

BUSY 

If  the  channel  is  busy,  the  next  statement 

is  skipped.   This  permits  "busy  wait"  - 

style  applications. 

DISABLE 

Prohibit  an  interrupt.   (If  the  channel 

was  busy,  it  stays  busy.) 

Allow  an  interrupt  again.   Critical  program 

sections  can  be  made  indivisible  with  these 

statements. 

expression 

The  TUTOR  expression  indicates  a  buffer  on 

which  the  channel  is  to  operate.   The  channel 

must  not  be  busy,  the  buffer  must  be  usable 

for  the  operation,  and  the  user  program  must 

not  COMPUTE  on  that  buffer. 

terminates  the  GET,  FREE,  and  OPEN  routines. 

relinquishes  control  of  the  CPU  by  the  INTERRUPT 
routine.   If  the  INTERRUPT  routine  consists  of 
RESUME  only,  interrupts  are  not  simulated,  buf- 
fering then  operates  a  channel  without  an 
interrupt  feature. 

The  expressions  involve  constants  and  variables.   All  values  are  integers; 


RETURN 


RESUME 
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expressions  follow  TUTOR  syntax.   We  have  the  (global)  variables  a  .  .  f , 
shared  by  all  input  -  output  supervisor  routines  and  the  user  program. 
The  COMPUTE  statement  in  the  user  program  requires  an  expression  indicating 
which  buffer  is  to  be  used.   Additionally  the  read-only  defined  names 
bufno,  rcomp,  and  rdata  can  be  employed. 

4.4  An  example  -  buffered  input 

OPEN  INPUT  where  bufno  >  1  is  assumed. 

0  CALC     b  <=  -  1,       b  will  indicate  the  COMPUTE  buffer 

1  CALC     f  <=  0,         f  buffers  are  full 

2  STARTIO  a  <=  0,         a  indicates  the  channel's  input  buffer 

3  RETURN 


GET  BUFFER 

0  IF 

1  JUMP 

2  CALC 


3 

RETURN 

COMPUTE 

b 

FREE  BUFFER 

0 

DISABLE 

1 

CALC 

f  ' 

2 

ENABLE 

3 

BUSY 

4 

STARTIO 

a, 

5 

RETURN 

JUMP  L 

f  =  0,         any  buffer  full? 
0,  no  -  busy  wait 

b  *=  mod  (b  +  1,  bufno), 

yes  -  advance  b  in  a  ring 

on  buffer  b 


for  the  sake  of  example 
f  -  1,      buffer  no  longer  full 

(if  statement  1  were  divisible, 
a  race  could  result) 
channel  available? 
yes  -  get  going 
in  any  case 
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and 


INTERRUPT  one  buffer  is  just  filled 

0  CALC      a  *°  mod  (a+1,  bufno), 

advance  a  in  a  ring 

1  IF        (f  <=  f+1)  <  bufno, 

all  buffers  full? 

2  STARTIO   a,  no  -  get  going 

3  RESUME  in  any  case 

no  race  is  possible  in  line  1  since 
only  one  interrupt  is  pending  at  any 
one  time 
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5.   semaphore 

5. 1  Purpose 

semaphore  is  another  system  programming  application  of  the 
csmini  programming  system.   It  provides  a  setting  in  which  the  student 
can  experiment  with  process  control  and  process  communication  in  a  multi- 
programming system.   The  lesson  supports  a  minilanguage  and  data-structures 
in  which  Dijkstra's  semaphores  [68]  and  other  synchronization  primitives 
can  be  implemented. 

semaphore  is  by  far  the  most  elaborate  application  and  adaption 
of  csmini .   At  the  time  it  narrowly  missed  the  absolute  bound  on  lesson 
size  on  the  PLATO  system.   Central  to  the  lesson  is  the  belief  that  a  matrix 
indexed  by  processes  and  waiting  lists,  whose  entry  for  a  process  is  its 
location  counter  on  the  dispatcher's  ready  list  or  on  a  waiting  list,  is 
an  effective  graphical  teaching  device  for  the  concept  of  process  control 
and  synchronization.   Once  the  device  was  successfully  applied  -  even  in 
an  embarrassingly  rudimentary  implementation  -  the  minilanguage  was 
developed  and  the  final  lesson  constructed. 

5. 2  Lesson  structure  and  synchronization  principles 

semaphore  uses  the  exact  same  structure  as  does  csmini:   the 
programming  system  consists  of  a  filing  system,  an  editor,  an  execution 
simulator,  and  a  help  sequence  (figure  1.1). 

The  filing  system  and  editors  are  copied  and  adapted  from  csmini. 
Examples  are  available  in  semaf ile  (the  standard  dataset  for  semaphore)  for 
Dijkstra's  P  and  V  primitives  solving  the  mutual  exclusion  problem  and 
implementing  process  communication  [Dijkstra  68],  for  an  alternate  imple- 
mentation of  the  P  and  V  operations,  for  the  ENQ,  DEQ,  WAIT,  and  POST  services 
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of  OS/360  [IBM  67],  for  a  generalization  of  the  P  and  V  primitives  to 
control  i  units  of  a  resource  at  once  and  for  various  dispatching 
strategies  (FIFO,  round  robin,  etc.)* 

The  help  sequence,  in  addition  to  explaining  the  minilanguage, 
discusses  the  design  philosophy  of  an  operating  system  simulated  by 
semaphore: 

An  operating  system  is  viewed  as  a  set  of  lists  of  sequential 
processes.   A  process  requests  from  the  operating  system  the  execution 
of  a  user  program;  user  programs  are  designed  by  the  student  and  then 
assigned  to  one  or  more  processes  for  execution.   Processes  execute  more 
or  less  in  parallel  and  can  communicate  with  each  other,  share  system 
resources,  and  generally  synchronize  their  mutual  activities. 

The  key  to  process  synchronization  is  the  organization  of  pro- 
cesses into  lists:   The  ready  list  initially  contains  all  processes  acti- 
vated by  the  user.   The  dispatcher  manages  the  ready  list,  a  process  is 
selected  from  the  list  and  awarded  one  time  slice,  i.e.,  a  certain  number 
of  statements  in  its  user  program  is  executed.   Dispatchers  are  designed 
by  the  student;  the  actual  simulation  commences  when  the  execution  of  a 
dispatcher  is  initiated. 

User  programs  may  call  on  list  managers  to  manipulate  any  of  a 
number  of  student-defined  lists.   List  managers  are  designed  by  the  stu- 
dent; they  can  transfer  their  caller  process  (which,  of  course,  is  currently 
on  the  ready  list)  or  any  other  process  from  their  own  or  the  ready  list 
onto  any  list.   List  managers  are  considered  part  of  the  operating  system, 
they  exit  to  the  dispatcher  so  that  a  new  process  may  be  selected  for 
execution. 
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Synchronization  mechanisms  are  implemented  by  the  student  as 
suitable  list  managers  -  an  example  is  given  below.   The  lesson  also 
permits  experimentation  with  dispatching  (scheduling)  strategies  (through 
implementation  of  the  dispatcher  itself,  and  through  the  strategies  in 
the  list  managers)  and  with  synchronization  concepts  (through  implementa- 
tion of  user  programs.) 

A  workspace  in  semaphore  consists  of  at  least  one  dispatcher, 
list  managers  and  user  programs.   Lists  are  defined  as  part  of  the  work- 
space, their  parameter  values  can  be  initialized  prior  to  execution.   User 
programs  in  the  workspace  are  assigned  to  processes.   (see  figure  5.1). 
Prior  to  execution  simulation,  a  linkage  phase  verifies  that  all  referenced 
lists  and  list  managers  exist.   This  check  originates  from  the  list  of 
processes  and  thus  involves  only  those  user  programs,  list  manager  names, 
and  list  names  which  are  accessible  during  the  simulation;  it  is  performed 
to  increase  execution  efficiency  by  eliminating  the  necessity  to  check 
repeatedly  at  runtime. 

During  execution,  the  active  programs  and  their  location  counters 
are  displayed  in  two  areas  (see  figure  5.2).   Each  area  can  be  individually 
locked  -  the  student  can  thus  take  the  point  of  view  of  the  operating  system 
(dispatchers  and  list  managers  locked) ,  of  a  process  (user  program  locked) ,  or 
of  the  CPU  (free  display) . 

Lists  are  symbolized  as  the  rows  of  a  matrix;  within  each  column 
a  process'  presence  on  a  list  is  symbolized  by  the  location  counter  of  the 
process  being  displayed  in  the  corresponding  row.   A  process1  progress  in 
the  system  then  manifests  itself  as  the  location  counter  moves  up  and  down 
and  changes  while  the  process  is  on  the  ready  list  and  selected  for  execution. 
The  process/list  matrix  ideally  demonstrates  mutual  exclusion  situations, 
message  consumption,  etc. 
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Figure   5.1:      Workspace  Directory 
(lesson   semaphore) 
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A  slightly  expanded  version  of  this  operating  system  simulation 
laboratory  was  implemented  in  PL/I  on  the  TR440  computer  of  the  University 
of  Ulm  as  project  in  a  course  on  systems  programming  [Schloerer  78]. 

5. 3  The  minilanguages 

semaphore  requires  three  minilanguages  -  one  for  each  kind  of 
program  which  the  student  may  construct.   The  languages  are  extensions  of 
a  common  kernel,  and  they  are  based  on  the  language  and  principles  de- 
scribed for  csmini. 

All  languages  permit  the  following  statements  which  are  identical 
in  usage  to  csmini: 

CALC      expression 
IF        expression 
JUMP      expression 
All  languages  permit  inspection  and  modification  of  the  (global)  variables 
a  .  .  j  alias  var(l)  . .  var(10)*. 

The  extension  for  user  programs  additionally  contains  two  more 

statements : 

STOP 

terminate  and  remove  this  process 

from  the  system. 

managername         listname 

execute  the  list  manager  for 

the  indicated  list  (^  ready). 

List  managers,  indeed,  can  be  called  for  various  lists;  this  corresponds  to 

the  fact  that  the  P  and  V  operations  [Dijkstra  68]  can  manipulate  various 

semaphores  within  an  application. 


*  Processes  do  not  have  local  variables.   On  PLATO  this  was  a  necessary 
evil;  in  the  TR440  project  this  shortcoming  was  eliminated. 
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The  language  extension  for  list  managers  contains  the  kernel  and 
additionally  the  following  three  statements: 


APPEND 


listname  *=  expression* 
the  expression  value  determines  a 
process  which  will  be  placed  at  the 
end  of  the  indicated  list. 


EXIT 


the  call  to  the  list  manager  is 
completed;  control  reverts  to  the 
dispatcher. 
OWN  expression 

the  expression  value  determines  a 
process;  the  next  statement  in  the 
list  manager  is  executed  if  the  process 
is  on  the  managed  list  and  skipped 
otherwise. 
APPEND  can  only  be  used  to  transfer  processes  from  the  ready  or  managed 
list  onto  other  lists;  this  restriction  was  imposed  to  encourage  a  certain 
amount  of  modularity  in  the  applications.   APPEND  places  processes  at  the 
end  of  the  indicated  list;  this  fact  is  published  to  simplify  the  realization 
of  various  management  strategies  (see  examples) . 

EXIT  deliberately  reverts  control  to  the  dispatcher  and  not  (which 
would  sometimes  be  possible)  to  the  calling  process;  list  manager  calls  are 
implemented  to  be  indivisible  (the  call  counts  as  one  unit  in  the  time 
slice  of  a  process)  and  the  dispatcher  is  always  in  control  afterwards  so 
that  a  new  scheduling  decision  may  be  made. 


*  During  editing,  this  statement  does  require  character  manipulation  -  the 
'listname  ♦*'  must  be  extracted. 
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List  managers  have  read-only  access  to  the  following  values: 


caller 


length 


own  (expression) 


random 


the  number  of  the  process  calling 

this  list  manager. 

the  number  of  processes  in  the 

managed  list. 

expression  is  a  position  in  the 

managed  list  (<_  length);  the  number 

of  the  process  in  that  position  is 

returned. 

a  random  value  between  1  and  'length' 

(constant  during  one  call  on  the  list 

manager) ;  supplied  to  simplify  random 

dispatching  strategies. 


In  order  to  simplify  the  implementation  of  various  synchronization 
concepts,  each  list  has  a  single  parameter  'parm',  an  integer  variable 
unique  to  the  list  which  the  list  manager  can  modify.   Typically,  'parm' 
would  be  the  value  of  a  semaphore  represented  by  the  list. 

The  language  extension  for  dispatchers  is  very  similar  to  the 
extension  for  list  managers.   It  contains  the  kernel  and  additionally  the 
following  four  statements: 

APPEND  listname  *°  expression 

a  process  can  thus  be  moved  from 
the  ready  list  to  any  list. 
PROCESS  expression 

the  expression  value  determines  a 
process  which  must  be  on  the  ready  list; 
this  process  is  then  executed  for  one 
time  slice. 


READY 


STOP 
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expression 

similarly  to  the  OWN  statement  the 
presence  of  a  process  on  the  ready  list 
determines  whether  or  not  the  next 
statement  is  skipped. 

the  operating  system  terminates. 


PROCESS  gives  control  to  the  specified  user  process.   The 
length  of  a  timeslice  is  a  parameter  of  the  simulation,  to  be  selected  by 
the  student.   It  designates  the  number  of  user  program  statements  at  most 
to  be  executed  before  the  dispatcher  regains  control.   Thus,  round  robin 
scheduling  strategies  are  possible. 

While  the  ready  list  has  no  parameter,  the  dispatcher  has  read- 
only access  to  the  'length'  of  the  ready  list,  to  'random'  which  is  con- 
stant between  PROCESS  statements,  and  to  process  numbers  on  the  ready 
list  via  'ready(position) ' . 

5.4  An  example:   Dijkstra's  P  and  V  primitives 

A  semaphore  would  be  represented  as  a  list,  the  parameter  of  the 
list  records  the  value  of  the  semaphore.   The  P  operation  can  be  implemented 
as  a  list  manager  as  follows: 

(parm  •*=  parm  -  1)  >_  0 

own  *=  caller 


0 

IF 

1 

EXIT 

2 

APPEND 

3 

EXIT 

Note  the  embedded  assignment  in  statement  0.   Also  note  that  'own'  can  be 
used  as  a  list  name  in  the  append  statement  so  that  the  list  manager  can 
operate  on  arbitrary  lists. 
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A  list  manager  for  V  with  random  reactivation  would  be: 


0  IF 

1  EXIT 

2  APPEND 

3  EXIT 


(parm  •*=  parm  +  1)  >  0 
ready  *=  own  (random) 


Similarly,  a  dispatcher  with  a  random  scheduling  strategy 


might  be : 


0 

IF 

1 

STOP 

2 

PROCESS 

3 

JUMP 

length  =  0,     deadlock: 

ready (random) 
0 


It  is  advisable,  to  introduce  delay  loops  into  the  critical 

section  of  the  user  program  to  increase  the  probability  of  actual  mutual 

exclusion: 

mutex 

a  «■  0 

(a  <=  a  +  1)  <  3 

2 

mutex 

0 

There  is  thus  one  list  'mutex'  and  in  order  to  synchronize  the 
processes  properly,  its  parameter  will  have  to  be  initialized  to  1. 


0 

P 

1 

CALC 

2 

IF 

3 

JUMP 

4 

V 

5 

JUMP 
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OTHER  APPLICATIONS 

6.   csdesign 
6.1  Purpose 

csdesign  was  written  to  graphically  demonstrate  the  branching 
structure  of  a  PLATO  lesson:   Students  interacting  with  a  lesson  usually 
control  their  own  path  through  the  lesson  by  means  of  the  branching  keys 
(NEXT,  BACK,  HELP,  etc.)  or,  if  the  author  provides  it,  by  multiple  choice 
arrows  or  through  the  TERM  feature. 

Most  of  these  branching  possibilities  are  explicitly  coded  with 
statements  such  as  next,  help,  etc.  in  the  originating  unit,  or  with  a 
term  statement  in  the  receiving  unit.   However,  the  action  of  the  BACK 
and  SHIFT  BACK  keys  depends  on  a  variety  of  context;  in  particular,  the 
HELP-type  keys  set  up  implicit  back  and  backl  statements  for  the  receiving 
unit  of  the  HELP  branch,  and  a  base  statement  in  some  traversed  unit  can 
set  up  or  clear  implicit  back  and  backl  statements  further  along  the  path. 
Using  the  imain  statement  an  author  might  even  arrange  for  branching  pos- 
sibilities to  be  set  up  at  the  beginning  of  every  new  (main)  unit. 

csdesign  provides  a  graph  of  this  branching  structure.   The  nodes 
of  the  graph  correspond  to  the  (main)  units  of  a  lesson,  the  edges  to 
student  controlled  branches  (figure  1.1).   A  graphical  editor  permits  the 
design  of  a  lesson  graph;  additionally  csdesign  can  simulate  the  execution  of 
the  graph  —  depending  on  the  branching  keys  pressed,  the  currently  active 
node  is  highlighted  (see  figure  6.1)  —  and  csdesign  can  take  a  lesson  graph 
and  compile  it  into  equivalent  TUTOR  code  (see  figure  6.2). 

Lesson  graphs  may  be  stored  on  disk.   The  filing  system  developed 
for  csmini  is  part  of  csdesign,  and  is  thus  put  to  quite  a  different  use. 
dsgnf ile,  the  standard  dataset  for  csdeisgn,  contains  two  examples:   a 
lesson  graph  for  the  mini  programming  systems,  and  a  lesson  graph  for  a  more 
tutorial  lesson. 
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csdesign  will  refuse  obvious  errors  such  as  duplicate  or  non- 
existent unit  names.   Global  simplification  of  the  lesson  graph,  however, 
is  not  attempted.   In  particular,  there  does  not  seem  to  be  an  algorithm 
to  deal  with  base  units  at  compile  time  (to  eliminate  unnecessary  base 
statements  and  to  display  all  base  relations). 

One  PLATO  consultant  commented  on  the  large  number  of  end  lesson 
statements  produced  by  the  lesson  graph  compiler:   In  the  absence  of  next 
or  multiple  choice  edges  the  NEXT  key  should  terminate  the  lesson  rather 
than  to  produce  the  well-known  phenomenon  of  blank  pages,  sentence  fragments 
on  the  screen,  and  finally  (usually)  some  spectacular  crash.   At  least  in 
this  respect  csdesign  attempts  to  produce  clean  code  and  protect  the  in- 
experienced author. 

6.2  The  editor 

The  editor  must  display  and  modify  the  lesson  graph  on  the  screen 
and  a  corresponding  data  structure  in  memory.  Input  to  the  editor  consists 
of  geometric  information  and  branching  keys  (see  figure  6.3). 

Geometric  information  is  the  position  of  the  cursor,  repositioned 
in  response  to  the  "arrow"  keys  or  to  a  touch  on  the  PLATO  screen.   This 
cursor  position  can  be  used  to  identify  a  node  (unit)  of  the  lesson  graph  — 
the  node  description  in  the  data  structure  can  be  found  on  the  basis  of 
coordinates.   In  response  to  other  input,  nodes  identified  by  the  cursor 
can  be  modified,  connected,  deleted,  etc.   Alternatively,  new  nodes  may  be 
introduced  to  reside  at  the  cursor  position,  or  existing  nodes  can  be 
repositioned. 
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Branching  keys  (NEXT,  TERM,  etc.)  request  that  a  corresponding 
link,  i.e.,  a  student-controlled  branch,  be  established.   Links  will 
either  connect  two  nodes,  or  they  will  relate  globally  to  one  node  (TERM 
and  branching  statements  introduced  with  an  imain  unit).   In  order  to 
establish  links,  nodes  must  be  identified  —  this  is  possible  by  (unit-) 
name,  cursor  position,  or  by  reference  to  the  last  node  added. 

A  special,  but  common,  variety  of  branching  depends  on  a  multiple 
choice  arrangement:   the  choices  are  usually  identified  by  single  letters; 
as  soon  as  a  letter  is  pressed  the  corresponding  branch  is  taken.   This 
structure  is  usually  realized  with  an  arrow  statement  and  (corresponding 
to  PLATO's  standard  editor)  the  '■*='  key  will  introduce  a  multiple  choice 
link  into  a  lesson  graph. 

6. 3  The  compiler 

The  following  information  can  be  obtained  for  each  node  (there 
is  more  information  specific  to  editing): 

names  of  this  unit 

of  base  unit  (if  any) 
global  key  (if  any) 

TERM  word  (if  any) 

Each  node  also  provides  access  to  a  list  of  outgoing  and  a  list 
of  incoming  links  (the  latter  to  speed  up  editing  operations) .   A  link 
provides  the  following  information  for  the  compiler: 

activating  key 

target  unit 
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The  compiler  is  given  the  name  of  the  unit  to  appear  first  in 
the  lesson,  i.e.,  the  unit  first  entered  when  the  lesson  is  accessed 
normally.   Then  code  is  compiled  as  follows: 


TUTOR  code 
define    mult=nl 
imain     KEYS 


unit 

term 
base 


<unitname> 

<tag> 
<  name  > 


<key>     <name> 


at 

1010 

write 

<unitname> 

at 

930 

write 

<letter> . . . <name> 


arrow 

2010 

long 

1 

exact 

jump 

<name> 

match 

mult,   letter  , 

jump 

mult ,x,  name  , . 

judge 

ignore 

Production  condition 

[always. ] 

if  any  unit  has  a  global 

key  pointing  to  it. 

[for  every  node  in  the  lesson 

graph,  see  below.] 

if  the  unit  has  a  TERM. 

if  the  unit  has  an  explicit 

base  unit  set. 

for  any  outgoing  branching 

key,  except  NEXT. 

[always,  to  document 

execution  of  this  code.] 

if  the  unit  has  outgoing 

multiple  choice  links. 

for  any  outgoing  multiple 

choice  link. 

if  the  unit  has  outgoing 

multiple  choice  links. 

if  the  unit  also  has  an 

outgoing  NEXT  key. 

for  all  outgoing 

multiple  choice  links. 
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next      <name>  if  there  was  no  multiple 

choice  and  if  the  NEXT  unit 
has  already  been  compiled 

end       lesson  if  there  was  no  multiple  choice 

and  no  outgoing  NEXT  link. 

The  compiler  will  now  select  another  unit.   If  the  target  of 
an  outgoing  NEXT  key  has  not  been  compiled  yet,  it  is  chosen  (to  clarify 
the  compiled  code);  otherwise  another  unit  is  chosen  sequentially  from 
the  beginning  of  the  node  storage.   Eventually  all  nodes  will  have  been 
compiled.   If  necessary,  unit  KEYS  is  then  produced  containing  all  the 
global  branching  keys  in  the  lesson  graph. 

Since  regular  TUTOR  lessons  are  not  permitted  to  write  into 
TUTOR  lessons,  the  compiled  code  is  deposited  in  common  storage*  and  the 
user  is  instructed  how  he  can  copy  the  code. 


*  The  filing  system  also  requires  common  storage.   The  compiler  was 
therefore  made  a  separate  lesson  csdesignc. 
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7.   csf low 
7. 1  Purpose 

Structured  coding  is  a  fashionable  word  usually  associated  with 
certain  programming  practices  such  as  relying  primarily  on  the  control 
structures  of  concatenation  (sequential  execution),  selection  (if-then- 
else  or  case) ,  and  iteration  (while  or  repeat-until) .   Nassi  and  Shneiderman 
[73]  suggested  a  flowcharting  technique  that  —  because  of  certain  topological 
properties  —  only  permits  these  control  structures  (figure  7.1)  and  thus 
strongly  encourages  clean  coding.   The  flowcharting  technique  does  not 
require  modern  programming  languages  to  accompany  it  —  this  author  has  used 
it  quite  successfully  in  introductory  FORTRAN  programming  courses. 

It  is  quite  simple  to  implement  the  normal  ('spaghetti')  variety  of 
flowcharts,  and  a  number  of  PLATO  lessons  do  so.   Producing  an  editor  for 
Nassi-Shneiderman  flowcharts  is  more  difficult,  mostly  because  the  editing 
dialogue  presents  a  semantic  problem:   How  do  we  talk  about  nesting  boxes? 

csf low  is  an  editor  for  Nassi-Shneiderman  flowcharts.   A  workspace 


consists  of  a  number  of  individually  named  charts  and  it  may  be  filed  using 
yet  another  copy  of  the  filing  system  discussed  earlier.   Among  the  examples 
in  f lowf ile,  the  standard  dataset  for  csf low,  are  the  usual  algorithms  found 
in  an  introductory  programming  course  (Euclid's  algorithm,  bubble  sort, 
Simpson's  Rule,  etc.)  and  a  few  more  challenging  applications:   Shell's  sort, 
and  an  program  to  justify  and  print  text. 

At  this  point,  flowcharts  constructed  in  csf low  cannot  be  'ex- 
ecuted' —  but  this  is  due  to  a  lack  of  time  to  write  some  execution  sim- 
ulator, not  because  there  are  any  actual  problems  in  such  an  extension.   The 
lesson  demonstrates  how  an  editing  dialogue  can  be  realized,  and  the 
algorithms  developed  for  the  editor  are  quite  independent  of  PLATO  or  any 
applications. 
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(help)  on    .  .  . 


C5FLOW 


Nass  l  -  Shne  l  clerman   F 1  owchart  3 


Flowcharts  according  to  this  proposal  permit   only 
a  limited  set  of  control  structures;  they  seem  to  be 
easier  to  verify  than  the  more  common   'spaghetti' 
diagrams.  The  flowcharts  evolve  as  a  nested  set  of 
act i  ons  (boxes)  ,  where  each  act i  on  as  we 1 1  as  each 
nest  has  exactly  one  entry  and  one  exit. 

Th  i  s  ed  i  t  or  support  s  t  lie  f o  1  1  ow  i  ng  four  act  i  ons : 


free:  action,  used   to  express 
an  arfo i  t  r ary  comput  at i  on . 


t  rue 

i  t  i  on 
fa  1  se 

cf,  used  to  express  selectior 
::■£'  one  of  two  alternatives. 


re 

peat 

.;"";  r~;i 

nd i t i on 

repeat,  used  to  express  the 
iteration  of  an  action  until 
a  condition  becomes  true. 


c  o 

nd i t i on 

while,  used  to  express  the 
iteration  of  an  action  until 
a 


>nd  i  t  i  on    i  s   t  rue    (poss  i  b  1  \ 


feftCKJ  any t  i  me . 


Figure  7.1:   Flowcharting  Principles 
(lesson  csflow) 
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7.2  The  editor 

The  editing  dialogue  is  forced:   the  flowchart  under  construction 
is  correct  (in  its  syntactic  sense)  at  all  times;  the  problem  of  taking  a 
structure  and  verifying  that  it,  indeed,  conforms  to  the  Nassi-Shneiderman 
proposal  is  carefully  avoided. 

In  order  to  maintain  correct  flowcharts  we  cannot  permit  geo- 
metrical operations  such  as  the  adding  of  new  actions,  i.e.,  the  drawing 
of  new  boxes,  as  sets  of  individual  lines  with  text  enclosed.   Instead  we 
allow  algorithmic  development  such  as 

concatenate  a  new  action,  which  is  a  selection  or  iteration 
or  unspecified,  to  an  existing  action  (or  first  into 
the  chart) . 
insert  a  new  action  into  an  existing  selection  or  iteration, 
nest  a  chain  of  actions  into  a  new  selection  or  loop, 
delete  a  chain  of  actions, 
convert  a  chain  of  actions  into  a  separate  (named) 

flowchart . 
copy  a  named  flowchart  into  the  present  chart,  concatenate 
it,  or  insert  it. 

Actions  are,  of  course,  identified  by  pointing  at  them  on  the 
screen  with  a  suitable  cursor.   (The  editor  is  summarized  in  figure  7.2, 
a  sample  flowchart  is  shown  in  figure  3.2). 

The  key  to  implementing  the  editor  lies  in  a  suitable  data 
structure  for  representing  a  flowchart.   This  data  structure  must  permit 
the  editing  operations  mentioned  above  (especially  nesting,  extracting,  and 
erasing  may  be  difficult,  and  PLATO  affords  very  little  processing  power 
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(help]   on     .  .  .  CSFL.OI.iJ 

F 1  oujchart    Ed  i  t  or 

arrow  keys,  touch  panel.  move  the  cursor  O  . 
The  other  editing  functions  usually  assume 
that  the  cursor  points  at  the  box  involved. 


I'edit]        change  the  text  inside  the  current  box 


(hekt'i' i  '1'r  fly jcopy]  concatenate  a.  new  action  (box)  to  the 
current  box  (or  as  first  box  of  the  flowchart) 
(T)  is  an  if,  ©  is  a  repeat,  (y)  is  a.  while,  Ihext] 
i  s  an  unspec  i  f  i  ed  act  i  on ;  [copy]  a  I  1  ows  an  ent  i  re 

QDGDCD  insert  a  new  action  as  first  one  of  the 
true/' false  part  of  if,  or  as  the  loop  part  of 
repeat  or  while  which  must  be  the  current  box. 

RT7j    insert  a  concatenated  set  of  boxes  (and 
all  boxes  within)  as  true/fa Ise  part  of  a  new 
if,  or  as  loop  part  of  a.  new  repeat  or  while. 
The  current  box  is  the  first  one  of  the  set, 
t  h  e  1  a  s  t  c  o  n  c  a  t  e  n  a  t  e  d  o  n  e  w  ill  b  e  r  eq  u  e  s  t  e  d . 


[erase]  erase  a  concatenated  set  of  boxes 


box  with  a  rou.ti.ne  name;   the  set  of  boxes  is 


;rat  i  on  that  has  not  vet  been  completed. 


r 


[back]  any t  i  me . 


Figure   7.2:      Flowchart   Editor  Options 
(lesson   csf low) 
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if  a  quick  response  is  required).   Additionally,  plotting  the  chart  and 

correlating  a  position  on  screen  to  the  representation  of  a  box  must  be 
efficient  operations. 

Surprisingly  enough,  the  data  structure  and  its  manipulation 

are  just  about  textbook  material  for  one-way  linked  lists  and  binary 
trees!   We  make  the  following  observations: 

a  concatenation  is  a  list  of  actions. 

an  if-action  has  two  dependent  concatenations,  namely  the 

true  and  false  alternatives, 
a  while-  or  repeat-action  has  one  dependent  concatenation, 

namely  the  subject  of  the  iteration, 
any  action,  if-,  while-,  repeat-,  or  unspecified,  has  some 

textual  content  and  participates  in  one  concatenation, 
a  flowchart,  finally,  is  one  concatenation. 

This  structure  seems  to  resemble  a  binary  tree  where  actions 
are  the  nodes,  if-actions  having  two  sons,  while-  and  repeat-actions 
having  one,  and  unspecified  actions  having  none.   However,  a  flaw  remains: 
the  concatenations  do  not  fit;  they  really  play  the  role  of  nodes,  composed 
of  many  atoms,  and  the  atoms  (actions)  then  provide  for  descendants  in 
the  tree.   The  data  structure  thus  is  not  quite  a  binary  tree,  but  all 
the  manipulation  algorithms  still  are  easily  developed  by  observing  the 
close  resemblance. 

actions  are  the  nodes  in  the  data  structure;  they  are  typed 
and  make  the  text  content  of  a  box  accessible. 
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every  node  has  a  successor;  the  successor  node  is  either  the 

concatenated  action  (if  any)  or  a  blind  node  designating 

the  end  of  a  concatenation, 
if-type  nodes  have  two  sons;  the  son  nodes  are  either  blind  or 

they  represent  the  first  actions  in  the  true  and  false 

alternatives  of  the  if-action. 
while-  and  repeat-type  nodes  have  one  son;  the  son  node  is 

blind  or  represents  the  first  action  subject  to  the  iteration, 
a  flowchart  then  is  a  header  with  a  son  node;  the  son  node  is 

blind  or  represents  the  first  action  in  the  flowchart. 

Plotting  a  flowchart  is  accomplished  by  traversing  the  representing 
tree.   With  a  given  left  and  right  margin  we  can  iteratively  move  along  the 
concatenation  and  down  the  screen: 

an  unspecified  action  is  plotted  over  the  entire  width  available. 

the  condition  of  an  if-action  is  shown,  then  the  son-concatenations 
are  (recursively)  traversed  in  turn  on  the  left  and  right  half 
of  the  screen,  finally  an  uneven  bottom  may  have  to  be  adjusted. 

the  condition  of  a  while-action  is  shown,  then  the  son-concaten- 
ation is  (recursively)  traversed  on  a  slightly  reduced  screen 
width,  finally  the  while-box  is  completed. 

a  repeat-action  is  similar  to  a  while-action,  the  difference  is 
that  the  condition  is  displayed  at  the  bottom  of  the  box. 

Plotting  is  thus  a  recursive  traversal  algorithm  with  left,  right 
and  top  margins  as  input  and  bottom  margin  as  output.   Each  node  must  only 
provide  its  own  height  (depending  on  the  given  width!)  it  need  not  know  its 
own  coordinates. 
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Finding  a  node  based  on  a  cursor  position  is  accomplished  by  a 
similar  traversal  which  performs  the  same  margin  computations  as  does  the 
plotting  algorithm,  but  which  does  not  actually  plot.   In  complete  analogy 
to  the  plotting  algorithm,  the  finder  can  distinguish  between  a  hit  into 
any  area  of  a  repeat-box  and  a  hit  into  the  actions  actually  repeated,  etc. 

Deletion  of  nodes  is,  of  course,  based  on  postorder  traversal; 
copying  a  chart  is  based  on  preorder  traversal.   A  sizing  traversal  (in 
preorder)  verifies  that  nesting  and  copying  will  not  produce  flowcharts 
too  detailed  to  be  displayed. 

Implementation  of  the  editor  is  a  simple  exercise  in  manipulating 
one-way  linked  lists  and  binary  trees.   Recursion  and  the  introduction  of 
the  blind  nodes  mentioned  above  make  programming  quite  straight-forward 
(although  in  TUTOR  the  recursion  must  be  simulated  through  explicit  stacks) , 

7 . 3  Implementation  notes 

The  crucial  algorithms  have  been  described  above.   Since  TUTOR 

does  not  permit  recursion  to  a  sufficient  depth,  the  following  technique 

is  used: 

unit  I(sparm(top+l) ,sret (top+1) ) 

calc  top  *=  top+1    push  the  stack 


we  define  parm=sparm(top)  and  can 
thus  use  a  'local  variable'  parm. 


goto  I (newvalue,returncode) 

this  establishes  a  'recursive  call' 

entry  II 

this  establishes  the  return  point 
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calc 
goto 


top  *=  top-1   pop  the  stack 
sret (top+1) , . . . , II , . . . 
this  will  return  from  the 
'recursive  call'. 


With  this  technique  it  is  possible  to  mechanically  convert 
a  recursive  solution  into  an  iterative  one.   The  necessary  stack  is 
maintained  in  bank();  it  is  dimensioned  so  that  all  plotting  algorithms 
cannot  overflow  it. 

In  the  file()  area,  csflow  allocates  control  information 
indicating  how  much  of  the  remaining  area  is  used,  a  fixed  area  of  nodes, 
and  a  fixed  area  for  text. 

Nodes  are  linked  to  form  list  of  available  nodes;  overlays  are 
defined  for  the  node  area  to  interpret  the  nodes  as  describing  boxes  or 
routines: 


routine  descriptor 
nxt() 

rnm() 
rnd() 

box  descriptor 
nxt() 

nty() 
nap() 


pointer  to  next  routine  node 

or  blind  node. 

6  letter  routine  name. 

pointer  to  first  flowchart  node 

or  blind  node. 

pointer  to  concatenated  box 

or  blind  node. 

node  type  field. 

pointer  into  text  storage  (see  below.) 
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nle()  pointer  to  left  and  right  sons 

nri()  or  blind  nodes,  if  any. 

Blind  nodes  have  nxt()  =  nil (zero)  —  they  simplify  all  node 
managing  operations. 

A  variable  avail  points  to  the  first  node  on  the  avail  list; 
one  location  (heaplen)  in  the  node  area  is  not  attached  to  the  avail  list. 
Typically,  to  attach  a  new  node,  the  appropriate  information  is  filled 
into  the  node  at  heaplen,  then  the  value  of  avail  is  assigned  to  the 
point  where  the  new  node  is  to  be  attached,  finally,  the  unit  getheap 
is  called  which  will  detach  the  next  available  node  from  the  avail  list 
and  copy  the  information  from  heaplen  into  it;  getheap  also  displays 
certain  statistics.   A  complementary  unit  f reeheap  will  return  a  node  to 
the  avail  list. 

Text  storage  is  organized  as  an  auxiliary  pointer  area,  apt(), 
to  which  the  nodes'  nap()  point.   The  auxiliary  pointers  then  locate  text 
in  the  actual  text  area.   If  text  is  moved,  the  auxiliary  pointers  can  be 
updated  sequentially  and  the  nodes  need  not  be  traversed.   The  auxiliary 
pointers  are  maintained  so  that  a  zero  indicates  an  available  pointer; 
the  search  statement  will  quickly  locate  this. 

Determining  the  height  of  a  box  once  the  width  is  prescribed  is 
a  frequent  operation.   It  amounts  to  counting  the  number  of  print  positions 
which  a  text  actually  requires  —  with  the  character  code  in  the  PLATO 
system,  where  a  variable  number  of  6  bit  codes  together  may  print  as  one 
character,  a  very  complicated  problem.   csf low  permits  texts  of  up  to  60 
characters;  when  a  text  is  newly  obtained,  a  bit  mask  of  one  60  bit 
word  is  constructed  which  is  '1'  on  every  last  character  in  a  print  sequence. 
The  number  of  printing  positions  is  then  the  number  of  '!'  bits  in  the  mask  — 
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a  very  fast  operation.   The  mask  is  also  used  in  breaking  text  correctly 
into  several  lines  of  a  box. 

The  sizes  of  the  text  areas  and  the  node  area  are  fixed,  based 
on  some  sample  workspaces.   A  better  solution  would  be  to  organize  them 
somewhat  dynamically. 
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OPEN  QUESTIONS 

The  mini  programming  systems  described  here  have  seen  use  in 
some  advanced  computer  science  courses,  and  they  seem  to  have  accomplished 
their  instructional  goals;  at  least  csmini  has  successfully  been  used  to 
support  a  programming  assignment  —  an  implementation  of  Wirth's  W-curves 
[76].   csflow  was  used  to  provide  information  for  a  machine  problem  in 
the  introductory  programming  course  in  summer  1978. 

While  the  filing  system  has  shown  to  be  quite  adaptable  to  a 
number  of  widely  differing  applications,  it  could  be  improved  by  employing 
some  new  PLATO  features: 

The  decision  to  employ  onely  one  common  for  all  lessons 
is  no  longer  necessary.   Datasets  can  now  be  reserved; 
hence,  exclusive  access  to  the  catalog  can  be  granted 
to  csminiadm  and  each  individual  lesson  based  on  a  data- 
set  reservation.   Users  of  one  lesson  still  need  to 
interlock,  but  overall  performance  would  be  improved. 

Name  sets  should  be  attached  to  provide  a  private  filing 
facility  keyed  to  the  student's  name.   While  the  standard 
examples  for  the  lessons  still  should  originate  from 
datasets  with  the  catalog  and  abstract  service  as  de- 
scribed here,  namesets  would  provide  easily  managed 
privacy  for  larger  class  assignments,  etc. 

The  strongest  feature  of  the  filing  system,  however,  is  its  basic 
ignorance  of  the  content  and  length  of  a  system  (disk  record) .   This  should 
by  all  means  by  retained. 
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The  mini languages  seem  to  be  rather  useful.   Only  minor  irrations 
were  discovered  -  mostly  in  the  area  of  global  and  local  variables  in 
semaphore.   The  implementation  of  a  number  of  protective  measures  within 
expressions  could  now  be  substantially  simplified  through  the  use  of  TUTOR' s 
arrays  with  subscript  bounds. 

There  is  still  a  large  number  of  possibilities  for  small 
languages: 

The  recursive  descent  parsing  technique  of  a  compiler 
requires  a  language  of  about  5  simple  statements 
[Schreiner  78],  and  there  are  more  compiler  algorithms 
that  could  be  adapted  to  this  environment. 

Coff man's  progress  plane  [71]  seems  to  be  a  very  good 
graphical  vehicle  to  discuss  process  scheduling,  dead- 
lock detection  and  Haberman's  algorithm  [69].   The 
simulation  of  the  progress  plane  is  available  on  PLATO 
in  lesson  deadlock  (see  figure  8.1)  but  it  is  not  really 
clear  how  this  concept  could  be  made  very  interactive  in 
a  fashion  similar  to  semaphore . 

A  minilanguage  for  sorting  could  be  based  on  a  situation 
where  a  randomly  initalized  array  of  'N'  things  needs  to 
be  sorted.   The  language  should  provide  testing  predicates, 
e.g., 

LE(i,j)    true  if  array  element  i  precedes 
element  j  in  the  assumed  ordering 
and  an  'exchange'  statement;  no  actual  access  to  the  array 
is  necessary.   (The  language  should  allow  recursion  to 
facilitate  an  implementation  of  'quicksort'.) 


Max.  Claim 


Resource  i 
Res  ource  2 


Process    2 
...    „  A 


0 
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The  progress  plane  definition  is  now  complete. 
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Figure  8.1:      Progress  Plane   Simulation 
(lesson  deadlock) 
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The  lesson  csf low  opens  up  an  entirely  different  area  of  ap- 
plications.  As  it  stands,  it  could  perfectly  act  as.  a  disciplined  flow- 
charting tool  and  as  such  could  be  employed,  e.g.,  in  an  introductory 
programming  course  for  submitting  flowcharts  and  thus  stressing  the  need 
to  design  clean  control  structures.   Expansion  of  the  lesson,  however, 
could  lead  to  quite  powerful  and  very  language- independent  programming 
environments:   Nassi-Shneiderman  flowcharts  would  then  be  a  well-structured 
language  kernel  providing  the  control  structures  commonly  found  in  a  modern 
programming  language;  the  language  extensions  for  particular  teaching  ap- 
plications can  completely  reside  inside  the  boxes  and  thus  on  top  of  the 
kernel. 

Maybe  it  is  just  about  time  to  rewrite  csmini  and  friends  . . . 
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